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Abstract. Data exchanges between Web services engaged in a composi- 
tion raise several heterogeneities. In this paper, we address the problem 
of data cardinality heterogeneity in a composition. Firstly, we build a 
theoretical framework to describe different aspects of Web services that 
relate to data cardinality, and secondly, we solve this problem by de- 
veloping a solution for cardinality mediation based on constraint logic 
programming. 
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1 Introduction 

Web services are independent software components that users or other peers 
can invoke in order to utilize their functionalities, like WeatherForecast and 
RoomBooking. Web services combine the benefits of service-oriented computing 
paradigm and platform- independent protocols (HTTP [8] ) to enable and sustain 
business-to-business collaborations. To make these collaborations happen and 
last for long periods of time, Web services rely on a set of XML-based protocols 
and languages that support their discovery (UDDI [TO]), description (WSDL [3]) 
and invocation (SOAP [2]). 

Composition orchestrates the functionalities of several Web services into the 
same loosely-coupled business processes to answer complex users' needs. Differ- 
ent languages exist to specify composition scenarios in terms of Web services to 
include, interactions to allow, exceptions to handle, just to cite a few. WS-BPEL is 
nowadays the defacto composition standard [4]. However despite this "battery" 
of protocols and languages, composition remains a tedious task. Web services 
continue to be designed in isolation from each other, which increases the levels 
of heterogeneities between them. In today's economy, it is unlikely that suppliers 
will develop the same types of Web services and comply with the same design 
options. 

In this paper, we look into these heterogeneities from a data-cardinality per- 
spective. Cardinality typically refers to the number of elements in a set or group, 



and is considered as a property of that grouping (Wordnct 1 ) . In the context of 
Web services composition, we refer to cardinality as the number of data instances 
contained in the messages that Web services engaged in composition exchange. 
Web services have different limitations in terms of minimum and maximum data 
cardinalities, and this for several reasons such as technical limitations, search 
for interoperability with specific partners, quality of service depending on the 
number of results provided, etc. We refer to these limitations as cardinality con- 
straints. Mismatching cardinality constraints will for sure hamper the smooth 
progress of a composition by making Web services, for example, indefinitely wait 
for the right number of elements or return invalid responses because of the lack of 
appropriate elements. Additional illustrative examples are provided throughout 
this paper. 

While cardinality heterogeneities have been tackled in the field of schema 
matching [7] , and despite the large amount of work on Web services mediation, 
the resolution of cardinality heterogeneities between Web services remains some- 
how marginalized. In [8], Nagarajan et al. present a classification of Web services 
heterogeneities. In spite of an exhaustive classification, the authors do not explic- 
itly mention cardinality heterogeneities. Instead, they mention an "entity level" 
category of data incompatibilities, to which cardinality heterogeneities belong. 
In the following, we specifically focus on cardinality heterogeneities, and assume 
that semantic and structural data heterogeneities are already fixed. 

The rest of this paper is structured as follows. Section [2] presents the vocab- 
ulary and theoretical background that was developed to tackle the cardinality 
concern. Section[3]lists the different cases of cardinality heterogeneities that arise 
between Web services. Section 2] describes the proposed solution along with its 
theoretical and implementation framework, prior to concluding in Section [5] 

2 Theoretical framework 

Our work starts by defining various concepts such as data flow, Web service, 
and composition. The purpose of these definitions is to formalize the cardinality 
issue, and provide a solid background for the proposed solution. 

2.1 Data flow representation 

A composition orchestrates several Web services into a business process. In this 
process, Web services typically manage data and exchange them with peers in 
compliance with some predefined flows. 

Characteristics of data flow: Fig. [1] illustrates a simple data flow between 
two Web services: data are passed on from a source Web service WS\ {sender) 
to a target Web service WS2 (receiver). These data are organized in terms of 
input and output messages that are structured using several parts. Each message 
part has a type described with an XML Schema |llj . This type may contain 
additional elements integrated into a complex structure. Cardinality constraints 



on data are expressed at the type level using minOccurs and maxOccurs XML 
Schema attributes. Examples of such constraints in Fig. [T] are [minAi,maxAi], 
[miriAP,mciXAp], [minAv ,maxAv], and [minAp> ,maxAP']- 
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Fig. 1. Simple data flow in a composition 



For simplification purposes, this paper deals with messages that contain one 
part with a data type that contains one couple of minOccurs and maxOccurs 
cardinality constraints. However, this does not limit the applicability of our 
solution to complex data structures and multi-part messages. 

Constraints on data flows: In a composition, different constraints that relate 
to the cardinality concern apply to data flows. We illustrate these constraints 
with the following examples: 

— Example 1: Editor WS\ sends data to printing WS2- 

— Example 2: Google-like WS\ sends data to mashup WS2. 

— Example 3: Shopping WS\ sends data for payment to banking WSv- 

Data selection constraint. Denotes the possibility of selecting some elements out 
of the data flow. In Example 1, data selection is not authorized, i.e., all data 
from W S± must be printed. Similarly, all shopping items must be processed by 
the banking Web service in Example 3. Data flows in both examples are not 
data-selection tolerant. In Example 2, WS2 only selects the first elements in the 
list, because search results are classified according to their relevance, and as a 
consequence the first results are the most relevant. If the mashup WS2 offers 
three entries for the search answers, only the first three results are selected. In 
this example, the data flow is data-selection tolerant. 

Duplicate constraint. Denotes whether receiver Web services tolerate incoming 
data with duplicate elements. In Examples 1 and 3, data flows are duplicate 
tolerant. Indeed, a same document can be printed several times, and a shopping 
item bought several times needs to be paid several times. In Example 2, dupli- 
cates are not tolerated and should be merged into a unique element, as users 
are not interested in duplicate search results, so the data flow is not duplicate 
tolerant. 



Ordering constraint. Relates to how much changes in the order of elements in 
the data flow are accepted. Both Data flows of examples 1 and 2 are not order- 
change tolerant, i.e., the order of transmitted elements needs to be maintained. 
Indeed, the order of search results is important to the user, and the order of 
printed documents in also relevant to the printing Web service. In Example 3, 
data flow is order-change tolerant, all the bought items have the same priority 
and the payment order does not affect the banking Web service. 

The aforementioned three types of constraints permit describing data flows 
along the following aspects: (i) data selection attribute (boolean) denotes whether 
specific parts of data can be selected, (ii) duplicate attribute (boolean) denotes 
whether duplicate elements are tolerated in the data flow, and (iii) ordering at- 
tribute (boolean) denotes whether the order of the elements must be conserved. 
This classification of constraints is particularly relevant during the cardinality- 
mediation exercise (Section 3]). Each attribute impacts the number and organi- 
zation of elements that Web services exchange and the mediation to adopt per 
type of constraint. 

2.2 Data schema and constraint representation 

To highlight the cardinality issue in the definition of data schema, we follow the 
definition of a schema graph given in [5]. A schema graph is a labeled directed 
graph with property sets. In this graph, nodes represent element types, edges 
represent relationships, and property sets on nodes or edges describe specific 
XML features. In this paper, we define a constrained schema as a schema graph 
with its cardinality constraints described via property sets, but we remind that 
property sets also describe other XML features in the original work [S] . 

Definition 1 (Constrained Schema). A constrained schema is a tuple CS = 
(ET,R,s,t,PS) where: 

- ET is a nonempty finite set of element types; 

- R C (ET x ET) is a finite set of relationships; 

- s : R —> ET is a function that indicates the source of a relationship; 

- t : R — > ET is a function that indicates the target of a relationship; 

- PS : {ET U R} x P — > V is a function that represents property sets, where 
P is a set of properties and V is a set of values including the null value. 

In the context of XML Schema. 7 = 1U§UDU {0} where M, S, U are sets 
of real numbers, strings, and user-defined labels, respectively. 

Definition 2 (Cardinality Constraint). A cardinality constraint k is a prop- 
erty of a constrained schema CS — (ET, R, s,t, PS), as aforementioned. This 
property is associated with a relationship r of CS and is defined as follows: 

- minCard: minCard(r) = i where i G H + ; 

- maxCard: maxCard(r) = j where j € N + and i < j. 

In the rest of this paper, a cardinality constraint on a relation r 6 R is denoted 
as k r = [£, j]. 



2.3 Web service representation 

We simply represent Web services as black boxes accepting inputs and returning 
outputs. Additionally, we consider the possibility for a Web service to be invoked 
several times and to return additional results. Such invocation possibility can be 
exploited for the purpose of cardinality mediation. 

Maximum number of invocations. Invoking a same Web service several 
times may help gather additional data for the purpose of cardinality mediation. 
However, some Web services cannot be indefinitely invoked when participating 
in a composition, for several reasons such as cost of the invocation, real world 
modifications, change of the Web service state, etc. For example, "add-to-cart" 
or "pay" operations of a shopping Web service must be invoked exactly once, 
as their executions make changes in the real world like updating a customer's 
banking account. On the contrary, some Web services can be indefinitely invoked 
without any changes in the environment, such as random number generator Web 
services. 

According to the characteristics detailed above, we provide a definition of 
Web services that includes all the relevant aspects to cardinality mediation: 

Definition 3 (Web service). A Web service WS along with respective cardi- 
nality constraints is defined as a tuple (ws,C 'Si n ,CSout, Inv max ) where, 

— ws is the Web service's identifier. 

— CSin and CSout are the constrained schemas that define the schema and 
cardinality constraints on data input and data output of ws. 

— Inv max is the maximum number of allowed invocations in the composition. 

For the purpose of cardinality mediation, we noticed a specific category of 
Web services that are indefinitely invocable and provide new data on each in- 
vocation. These Web services present interesting characteristics for cardinality 
mediation as they allow gathering new data on each invocation and thus they 
can to a certain extent fulfill the cardinality constraints of other Web services 
in case of lack of data. We qualify these Web services as data providers. Data 
provider Web services include: (i) biological Web service that sends pieces of 
DNA information, (ii) mathematical Web services that generate random num- 
bers, (iii) Web services that give up-to-date information on a patient (heartbeat, 
blood pressure, etc.), (iv) geographical localization Web services, (v) weather 
Web services, etc. 

2.4 Constrained composition representation 

A constrained composition is represented as a combination of Web services and 
data flows with shared constraints. Indeed, two data flows connecting to the 
same Web service share the constraint on its maximum number of invocations. 



Definition 4 (Constrained Web services composition). A constrained Web 
services composition C is defined as a set of Web services WS and data flows 
df where a data flow is defined as a tuple {WS S , WS r , dup, sel, ord), WS S is the 
sender Web service, WS r is the receiver Web service, dup expresses the tolerance 
to duplicates, sel expresses the possibility to select data in the data flow, and ord 
denotes whether the order of data elements must be conserved. 

To graphically model a constrained Web services composition and facilitate 
cardinality mediation, a labeled directed graph representation with property sets 
is adopted (Fig. [2]). In this graph, Web services and data flows correspond to 
nodes and edges, respectively. A Web service is represented by its constrained 
input and output schemas and a property that describes the maximum number 
of times it can be invoked in the composition. An edge has three constraints 
respectively related to data selection, duplicates and ordering. In Fig. [5] a simple 
data flow between WS\ and WS2 is represented. The properties in this data 
flow are: data selection is not allowed, data ordering must be conserved, and 
data duplicates are tolerated. Properties associated with Web services are as 
follows: Editor WS\ can be invoked at most once, and printing WS2 can be 
invoked as many times as required. 
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Fig. 2. Editor WSi sending out documents to printing WS2 



3 Classification of cardinality heterogeneities 

Let us consider the composition of Fig. [21 WS\ generates a list of elements that 
comply with a constrained schema CS\ ou t = {ET, R, s,t, PSi ou t) and WS2 re- 
quires the reception of elements that comply with a constrained schema CS^m = 
(ET, R, s, t, PS2in)- In such a composition, cardinality constraints compatibility 
consists in checking out if the constraints PS\ ou t and -PSWra are compatible^. 

Given two cardinality constraints k r \ = [i,j] G PSi ou t and fc r 2 = [m,n] G 
PSzin, respectively associated with CS\ ou t and CS^m, different correspondence 
cases can be identified as shown below: 

Case a. j < m: Guaranteed lack of elements. To be executed, WS2 needs at 
least m elements from WS\. However, WS\ can return at most j elements, 

1 We remind the reader our work is limited to one couple of constraints per schema 
for simplicity purpose. 
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Fig. 3. Cardinality constraints compatibility cases 

which is less than needed. As a result, there is a lack of required elements to 

make a WS2 invocation possible. 
Case b. i < m Am < j < n: Potential lack of elements. A lack of elements will 

only occur if, at runtime, the number of data instances in the WS\ result 

is smaller than the minimum number of elements expected by WS2 as an 

input. Otherwise, cardinality constraints PS\ ou t and P£>2»n are compatible. 
Case c. i > m A j < n: No cardinality constraints compatibility. 
Case d. m<i<nAj>n: Potential overabundance. When invoked, the Web 

service WS2 might receive more elements than needed. There is therefore a 

potential overabundance of elements when WS2 is invoked. 
Case e. i > n: Guaranteed overabundance. When invoked, the Web service 

WS2 will receive more elements than needed. There is therefore a guaranteed 

overabundance of elements when WS2 is invoked. 
Case f. i < m/\j > n: Potential lack and overabundance. Depending on the real 

number of elements of the WS\ result, a lack or overabundance of elements 

might occur as explained previously. 

Total satisfaction of constrained schema compatibility only happens in case c. 
However, in the other cases, it is still possible to reconcile cardinality constraints 
of Web services by applying appropriate mediation strategies. We remind that 
cardinality mediation occurs at the instance level. Then, we can group different 
schema-level heterogeneities into common mediation cases. 

— Lack of elements: cases a and b, possibly case f. 

— Overabundance of elements: cases d and e, possibly case f. 

We note that case f, depending on the actual number of instances sent, may 
belong to the "lack of elements" situation, to the "overabundance of elements" 
situation. 





4 Cardinality mediation for Web services 

In this section, we rely on the theoretical framework developed previously and 
propose a solution based on constraint logic to handle data cardinality in Web 
services composition. First, we describe the requirements of cardinality media- 
tion for a data flow, and show how these requirements apply by extension to a 
composition ; second, we quickly introduce constraint logic and show its rele- 
vance for the purpose of describing the requirements of cardinality mediation ; 
and third we present the sets of constraints we developed and show their appli- 
cability with a graphical data flow simulation implementation. 

4.1 Requirements of cardinality mediation 

Cardinality mediation requires complex computations in order to adapt data 
flows between Web services. In the following, we formally describe the require- 
ments for obtaining successful cardinality mediation in a data flow. We identify 
different situations depending on the duplicate tolerant and data selection tol- 
erant constraints on the data flow, and explain how the ordering constraint is 
dealt with. 

In order to demonstrate the requirements of cardinality mediation, we con- 
sider a data flow between two Web services WS\ and WS2, with structurally 
matching constrained schemas CSi out and CS^m- CSi out holds a constraint 
k r i — [a,b] and CS2i n holds a constraint fc r2 = [x,y]. We also define the num- 
ber of invocations m and n of WS\ and WS2 respectively, [a, 6] and [x, y] are 
intervals that represent the possible number of instances that can be obtained 
on one invocation of WS\ and WS2 respectively, and the operator * applies to 
these intervals as follows: m * [a, b] is equivalent to [m * a, m * b] to represent the 
number of instances that can be obtained after m invocations of a Web service. 

Duplicate tolerant /data selection untolerant data flows. Let us consider 
that the aforementioned data flow is duplicate tolerant and data selection un- 
tolerant, with k r \ = [9, 11] and k r 2 — [6,80. At first sight, k r \ cannot meet the 
cardinality constraints of k r 2- Indeed, a first call to WS\ binds k r \ to [9, 11] and 
a second call to WS\ binds k r \ to [18, 22], and both do not match k T 2- 

However, we notice that three invocations to WS2 bind fc r 2 to [18, 24]. Then, 
a reconciliation between WS\ and WS% is possible if WS\ is invoked twice and 
WS2 is invoked three times, as in this case k r \ C fc r 2- Hence, the number of 
elements required by WS2 is provided by WS\. By extrapolation, we devise 
when a cardinality mediation for this type of data flow is probably successful 
when: 

3m, n 6 (N+) 2 such that (m * [a, b]) D (n * [x, y]) ^ 0. 

2 Such cardinality constraints are improbable but they illustrate the complexity of 
cardinality mediation and show that our solution is applicable to any couples of 
constraints. 



This situation becomes more and more unlikely to happen as n grows and as 
(m * [a, b}) (~1 n * [x, y] becomes small. Accordingly, cardinality mediation for this 
type of data flow is certain to be successful when: 

Elm, n g (N + ) 2 such that (to * [a, b]) C (n * [x, y]), 

X 777 y 

which means that to and n verify the following condition: — ^ — < — . We 

a n b 

remind that such condition applies to duplicate tolerant and data selection un- 
tolerant data flows only. 

Duplicate tolerant/data selection tolerant data flows. Duplicate and 
data selection tolerant data flows need calling WS\ as many times as required 
to exceeding the minimal cardinality required by WS2, and then select elements 
depending on the users' selection policy (the "select" operation is detailed be- 
low). The formal representation is trivial and is: 

3m e N + such that (to * a) > x, 

Duplicate untolerant /data selection untolerant data flows. In duplicate 
untolerant data flows the number of duplicates in a message part is undeter- 
mined. Hence, the number of unique elements contained in a message part may 
vary between and the maximum number of elements. On a single run of W S\ , 
the number of unique elements contained in CS\ out is bound between and n*b. 
As duplicate detection and removal applies to the instance level, it is not possi- 
ble to determine a priori whether or not cardinality mediation will be successful. 
However, it is possible to describe it at runtime. 

Being given i the number of data instances returned by WS\ and a function 
/ that remove duplicates, cardinality mediation for a data selection untolerant, 
duplicate untolerant data flow successful when: 

3n g N+ such that f(i) g (n * [x,y]). 

Duplicate untolerant /data selection tolerant data flows. Accordingly, if 
data selection is allowed, then cardinality mediation is successful when: 

3n g N+ such that f(i) ^ (n*x). 

Ordering on data flows, ft is not possible to determine order-change tolerance 
without the intervention of the composition designer. Then, the data ordering is 
left to the user via an user interface that interacts with the user if necessary. If the 
data flow supports unordered lists, the cardinality mediator simply concatenates 
data elements. If ordering is important, alternative strategies are proposed to 
the user (concatenation of results, mixing of results depending on an algorithm, 
or manual ordering). 



Application to a composition. In this section, we presented the requirements 
of a composition for one data flow. Indeed, these requirements can be scaled up to 
a composition. In such case, numbers of invocations m, n, cardinality constraints 
[a, b], [x,y] are shared between several data flows. Such situations reduces the 
number of possibilities of the composition to succeed, however it simplifies the 
resolution of cardinality requirements as it provides a unified view of the whole 
business process with all the cardinality constraints. 

4.2 Constraint logic for cardinality mediation 

It turns out that constraint logic programming is well-suited for modelling car- 
dinality mediation. More precisely, constraint logic programming over finite do- 
main variables allows to specify constraints over these variables and to use these 
constraints in an a priori way to reduce the search space. The resulting framework 
is quite elegant since, on the one hand, it conserves the declarative expression 
of logic programming, including the multi-directionalities of its queries, and, on 
the other hand, it integrates an efficient way of solving constraints. 

This is very appealing in our cardinality mediation context. For instance, the 
following predicate basicjmediation(A, B, X, Y, M, N, D, S) aims at determining 
whether there are M, N such that M * [A,B] is a subset of N * [N,M] for 
a duplicate tolerant and data selection untolerant data flow. Such predicate 
describes the constraints we devised: 

bas i c_medi at ion(A,B,X,Y,M,N, Mmax , Nmax , D , S ) : - 

f d_domain( [M] , 1 , Mmax) , 
f d_domain( [N] , 1 , Nmax) , 
N * X #=<# M * A, 
M * B #=<# N * Y, 
fd_labeling([M,N]) . 

The couples A, B and X, Y represent the cardinality constraints of respec- 
tively WSi and WS2, M, N are the number of invocations of WS\ and WS2 to 
be found, Mmax and Nmax their maximum number of possible invocations, D 
and S are booleans that describe duplicate tolerance and data selection respec- 
tively. 

The code first defines the intervals [L.Mmax] and [I. .Nmax] as finite domains 
for the variables M and N and then specifies the constraints as given before, with 
the symbols #=<# indicating the less than equal relation. Finally, the fdJabeling 
predicate is used to start an exhaustive search but by first fixing a value for M, 
then by propagating this value in the constraints to reduce the domain of N and 
finally by searching in the reduced domain N for a value. 

An example is worth to capture what this means. Let us consider two Web 
services that hold [9, 11] and [6, 8] as cardinality constraints. The corresponding 
query is basic-mediation(9, 11, 6, 8, M, N, 10, 10, true, false). Thus the domains 
of M and N are both limited to [1..10]. Then M is fixed to 1 and the constraints 



become N * 6 ^ 9 and 11 ^ N * 8. All the possible values of N are then searched 
but there is no integer value of N that is comprised between 11/8 and 9/6. Then 
M is fixed to 2 and the constraints become N * 6 ^ 18 and 22 TV * 8. In 
such case, N — 3 is comprised between 22/8 and 18/6. Hence, the first solution 
returned by the Prolog engine is the couple of values (M = 2,N = 3). Other 
solutions are possible but they require additional invocations of WS\ or WS%, 
thus the first solution is the most interesting one. 

4.3 Implementation 

We developed a proof-of-concept prototype tool that simulates a data flow be- 
tween Web services and shows the possibilities offered by our cardinality me- 
diation approach (Figure 2]). This prototype tool relies on Java platform, and 
connects to a Prolog reasoner that contains cardinality mediation functions en- 
coded as shown in the above. Our Java program is a client application and the 
Prolog engine is currently deployed in a Web server as a CGI program that relies 
on GNU Prolog [5]. The Java program is actually a CGI client and user fron- 
tend, its performs the CGI calls and interacts with the end-user. The mediation 
process is performed by the Prolog engine, it depends on the constraints on Web 
services and data flow entered via the interface. 

Our solution operates as follows: for each data flow, the end-user feeds a 
Prolog engine with the different constraints on Web services and data flow via 
our graphical interface. Then, the Prolog engine calculates the possibilities to 
obtain a successful result and selects the best result if found. 

The constraints are a priori required and the user needs to provide them be- 
fore runtime. These are the constraints on the maximum number of executions 
for WS\ and WS2, together with the constraints on data flow (Data selection, 
duplicates and ordering), which are described neither in typical (WS-BPEL) 
business processes nor in typical Web service descriptions (WSDL). We are cur- 
rently working on a Web service composition platform that connects to our 
cardinality mediation simulator and feeds it with the composition parameters, 
in order to apply our constraint-based reasoning to the whole composition. 

Cardinality mediation involves different operations on data flows. We defined 
the following operations: 

— select(0, strategy) selects particular elements of the result set O depending 
on a user selection strategy (first elements, each two elements, last elements, 
manual selection. . . ) 

— merge(Oi,C>2, strategy) merges lists of results 0\ and O2 depending on a 
user merging strategy (concatenate elements of the second call to the first, 
mix each two elements, concatenate elements of the first call to the second, 
manual merging. . . ) 

— rm-dup{0, strategy) removes all the duplicates in O according to a user 
selection strategy (remove first duplicate first, remove last duplicate first). 

These operations are performed with the help of the user via the graphical 
interface. 
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Fig. 4. Scrccnshot of the data cardinality mediation simulator 



5 Conclusion 

In this paper, we shed the light on an important issue that could refrain the 
smooth progress of service composition scenarios if not addressed properly. This 
issue, which we referred to as cardinality heterogeneity, stresses out the im- 
portance of quantifying the data that Web services engaged in these scenarios 
exchange. Little research work has been done to address this issue. In this paper, 
we proposed a classification of cardinality heterogeneities and highlighted for ex- 
ample how a Web service could be overloaded with data that it might not need, 
and how lack of expected data could degrade the Web service compostition. A 
constraint logic-based cardinality mediation approach is proposed. It aims to 
adapt data flows between Web services by considering the requirements of both 
data flows in terms of tolerance to duplicate, selection and ordering, and Web 
services in terms of number of allowed invocations and constrained schemas. 

As a future work, we intend to study how different heterogeneous web services 
providing a same functionality could be combined to cover the cardinality con- 
straint of a service. A Web services community-based approach could be adopted. 
We are also interested in handling data cardinality of web services in the context 
of data privacy where some data might be hidden or shown depending on the 
existing privacy policies. 
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